home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19951130-19960209 / 000258_news@columbia.edu _Tue Jan 9 03:22:56 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.35.159]) by watsun.cc.columbia.edu (8.7.3/8.7.3) with ESMTP id DAA20749 for <kermit.misc@watsun>; Tue, 9 Jan 1996 03:22:56 -0500 (EST)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.3/8.7.3) id DAA07795 for kermit.misc@watsun; Tue, 9 Jan 1996 03:22:53 -0500 (EST)
  4. Path: news.columbia.edu!panix!bloom-beacon.mit.edu!gatech!newsfeed.internetmci.com!in2.uu.net!hilbert.dnai.com!news.zeitgeist.net!news.pixi.com!godzilla05
  5. From: chip@pixi.com (William K. Marshall)
  6. Newsgroups: comp.protocols.kermit.misc,comp.protocols.misc
  7. Subject: Re: No handshake xfers
  8. Date: Mon, 08 Jan 96 10:49:55 GMT
  9. Organization: Pacific Information eXchange, Inc.
  10. Lines: 65
  11. Message-ID: <4ct372$l8i@rigel.pixi.com>
  12. References: <4cqnvm$iii@rigel.pixi.com> <1996Jan8.125039.70773@cc.usu.edu>
  13. NNTP-Posting-Host: godzilla05.pixi.com
  14. X-Newsreader: News Xpress Version 1.0 Beta #4
  15. Xref: news.columbia.edu comp.protocols.kermit.misc:4454 comp.protocols.misc:5232
  16.  
  17. In article <1996Jan8.125039.70773@cc.usu.edu>,
  18.    jrd@cc.usu.edu (Joe Doupnik) wrote:
  19. >In article <4cqnvm$iii@rigel.pixi.com>, chip@pixi.com (William K. Marshall) 
  20. writes:
  21. >> Here's one for you all...
  22. >> 
  23. >> I am trying to set up a way to transfer from the unclassified LAN at my 
  24. >> workplace to the classified LAN.  I am using a batch file, Procomm Plus 
  25. with a 
  26. >> direct connection to the serial port,and two fiber optic modems with only 
  27. the 
  28. >> transmit side on the unclass connected to the recieve side of the class.  
  29. The 
  30. >> only way I have been able to accomplish this is to zip the files, uuencode 
  31. the 
  32. >> zip file and transfer usin plain ASCII.  This is fine, it works very well, 
  33. but 
  34. >> It takes about 4 hours to transmit 10 Meg.  
  35. >> 
  36. >> The problem with using something like Kermit or Zmodem is that the software 
  37. >> wants to see some handshaking.  Is there someone out there who knows of a 
  38. >> binary protocol that does not require handshaking, or is there a way to 
  39. turn 
  40. >> it off on any others?
  41. >> 
  42. >> Any and all assistance is appreciated.
  43. >> 
  44. >> William K. Marshall
  45. >> chip@pixi.com
  46. >---------------
  47. >    Dream on. No ACKs mean no protocol level flow control (and really
  48. >no flow control at all for the truely paranoid situations), no feedback
  49. >to the transmitter that information has become lost or damaged, no breaking
  50. >deadlocks from lost information. A straight ASCII send and hope that it gets
  51. >there also provides no error checking, no redundancy checking, no hole
  52. >checking. In short, it's *The Worst Way* of transferring information.
  53. >    I would suggest you get together with your security people and
  54. >discover that normal ACKs do not convey sensitive information and are
  55. >required for robust transfers. Put a packet snoop on the wire and see this
  56. >for yourself, particularly with Kermit file protocol transfers.
  57. >    Joe D.
  58.  
  59.  
  60. The thing is that I am only using a 4 foot lenght of fiber between two 486's. 
  61. The possibility for packet loss is remote.  It is not a big deal if once in a 
  62. while the users have to re-send the data.
  63.  
  64. As for the security people... I am in the military.  Just getting the 
  65. permission to connect two computers in the way I have described took over a 
  66. year, and the requirement for this is now.
  67.  
  68. If I connect the transmit side from the classified side to the unclass side, 
  69. there is a possibility of transferring data that way.  Even if there is a way 
  70. to turn the transfer off with the software, if someone knew how, they could 
  71. turn it on and transfer the data.  
  72.  
  73. It is a little different if there is no hardware to do this with.  It takes 
  74. out the possibility of someone hacking or fat fingering thier way to an 
  75. unapproved transfer.
  76.  
  77. Thanks,
  78. Chip
  79.  
  80. William K. Marshall
  81. chip@pixi.com